プロダクトマネジメント ビルドトラップを避け顧客に価値を届ける

https://gyazo.com/ed2c78af8f56058b197a5162e68d8584

なぜこの本を読んだか

最近、本業で新規にサービスを開発をしていたので改めてプロダクトマネジメント周りの知識をアップデートしたかったから。

何が書かれている本か

顧客への価値 (アウトカム) ではなく、リリース数や機能数などアウトプットに着目してしまった結果ユーザーが欲しいものが継続的に作られないプロダクト、チーム、組織になっているような状態 (ビルドトラップ) を避けるにはという本

ビルドトラップとは、組織がアウトカムではなくアウトプットで成功を計測しようとして、行き詰まっている状況のことです。

これが全てって感じの本

プロジェクトは、プロダクト開発の欠かせない一部ではありますが、プロジェクトだけ考えるという発想は悪影響を及ぼします。

プロダクトは育てていく必要があるもので、成熟に向けて成長していきます。これには時間がかかります。プロダクトを強化する機能をリリースすることは、この全体的な成功への貢献を意味します。機能の強化自体はプロジェクトですが、それが終わってもあなたの仕事は終わりません。全体的なアウトカムを実現し成功に至るまで、新しいプロジェクトを決めて、繰り返しやっていく必要があるのです。

メモ

企業のありかた

セールス主導

プロダクトロードマップと方向性は、顧客への約束によって決まる

e.g. 営業が強い会社とか

ビジョナリー主導

ある特定のワンマンがプロダクトロードマップと方向性を決める

e.g. スティーブジョブスがいた Apple とか

テクノロジー主導

最新のクールなテクノロジーを軸に進む

e.g. VR, ARとか

プロダクト主導

ビジネスアウトカムを軸に最適化し、プロダクト戦略を自分たちの目標に合わせて調整する

プロダクトの持続的な成長の原動力になるような一番効果的なプロジェクトに優先して取り組みます

プロダクトマネジメントとは

プロダクト開発は不確実性に満ちています。事実と、学習する必要があることを分離するのが重要です。

https://gyazo.com/944bffbf63c2b074920fd4d666579c99

つまり「既知に既知」から初めて「未知の未知」を減らしていくということが重要

悪い プロダクトマネージャーの典型

ミニCEO

プロダクトに対してリードする責任と権限はあるが、ビジョナリーになる (思い通りにする) ことが仕事ではない

ウエイター

全てを聞くだけで意思決定を行わない

プロダクトの死のサイクルに陥る危険がある

https://gyazo.com/42647609fec2dfef4752196876a55941

プロダクトマネージャーの仕事領域

戦術的な仕事

機能を作って世に出すという短期的な行動

戦略的な仕事

マーケットで勝利して目標を達成するためのプロダクトや会社のポジションを考える

運営

戦略と戦術を結びつけるためにロードマップを作成したりなどの登り方を考える

戦略とは？

戦略とは実行可能な意思決定のフレームワークであり、現在のコンテキストとの整合性を保ちながら、現在の能力の制約のもとで望ましいアウトカムを達成するための行動を可能にするためのものである。

The Art of Actiion

例えば、自分以外のメンバーが意思決定を下す際の根拠になるようなもの

命令を上から下に流していくのではなく、それぞれの階層でなぜそれが必要なのかの認識をそろえて、どうやってそれを実現するのかは下の階層に任せて報告してもらうようにすべき

最上位のリーダーたちが足並みが揃っていなければ、問題はチームにまで普及します

プロダクトのカタ

https://gyazo.com/966b54848237ccb41777206c828463a1

以下の質問を意識していく

1. 目標は何か？

2. 目標を踏まえて、自分たちは今どこにいるのか？

3. 目標に到達する上で立ちはだかる最大の問題や障害は何か？

4. どうやってその問題を解決するか？

5. 何が起こると予想されるか？ (仮説)

6. 実際には何が起こったか、そこから何を学んだか？

プロダクトの指標

AARRR

Aquision

Activation

Retension

Referral

Revenue

HEART

Happiness

Engagement

Adaption

Retension

Task Completion

問題の探索

検証的調査

ユーザーが簡単にソリューションを使えるかどうか (仮説も問題もわかっていてソリューションの検証に使う)

生成的調査

解決したい問題を見つける

学習のための実験

何かを作るときには２つのモードがある

学習のために何かを作る

作ったものは最終的に廃棄して、うまくいったのであれば、持続的でスケール可能なやり方を見つけなければいけない

収益のために何かを作る

MVPの誤解

MVPは「リーン・スタートアップ」の本の中で「学習のために何かを作る」に分類されているにもかかわらず理想的な状態を目指そうとする。

どちらかとえいば、ソリューションを検証、実験可能な最小の形という意味

筆者は、「学習のための最小の労力」と定義している

実験の方法

コンシェルジュ

実際に手動でユーザーと蜜なコミュニケーションを取って対応する

オズの魔法使い

コンシェルジュに近いが、手動でやっていることを悟られないようなインターフェースにする

つまり

https://www.youtube.com/watch?v=sfmwAvZuNvs

コンセプトテスト

コンセプト動画などを見せることで反応を見る

こういう実験が必要ない場合もある。こういった実験はあくまでも不確実性が高くて大きな開発リソースなどが無駄になってしまうようなリスクを避けるためにある。実装のコストが小さく、ABテストなどで実際に実装してしまえばいいような場合には実験は不要となる。 (ABも実験の一種ではあるが)

学習は「未知の未知」を減らし、リスクを軽減する

プロダクトが大きくなってきたら

「プロダクトオペレーション」という全てのプロダクトマネージャーが共通でするような仕事や共通の指標、言葉で会話ができるように社内横断で合理化するような業務を導入すると良い

感想

プロダクト作りをしている人全員に理解して欲しい1冊という感じだった

架空の会社をベースにビルドトラップに陥った企業を改善していくというのが理解しやすかった

プロダクトマネージャーでこういうことを理解していなかったら、この本を送りつけることにした